home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13735 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB
  1. Path: kai.com!not-for-mail
  2. From: robison@kai.com (Arch Robison)
  3. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Date: 26 Mar 1996 10:14:15 -0600
  6. Organization: Kuck & Associates, Inc.
  7. Message-ID: <4j954n$mrq@kai.com>
  8. References: <Doq3sv.MzA@research.att.com> <1996Mar25.160011.13921@schbbs.mot.com>
  9. NNTP-Posting-Host: kai.com
  10.  
  11. In article <1996Mar25.160011.13921@schbbs.mot.com> shang@corp.mot.com writes:
  12. >In article <Doq3sv.MzA@research.att.com> bs@research.att.com (Bjarne Stroustrup  
  13. ><9758-26353> 0112760) writes:
  14. >These conditions are not errors but only require some extraordinary work.
  15. >Similar examples were also given by Bill Foote in his previous post.
  16. >It is not hard for people to figure out more examples that requires the
  17. >following struture:
  18.  
  19. I think that you missed the point of Bjarne Stroustrup's post.
  20. It is easy to think of examples supporting any language feature.
  21. The point is that people actually programming with real languages
  22. on real projects found that resumption semantics were inferior
  23. to termination semantics.
  24.  
  25. Stroustrup was kind enough not to post his whole Design and Evolution (D&E)
  26. book.  Go read it.  Section 16.6 says more than the post.  Section 16.6.1 
  27. explains how to get most of the benefits of resumption semantics with C++.
  28.  
  29. > result    = try do_something()
  30. >      {
  31. >        when condition1: some_extraordinary_work1; retry;
  32. >        when condition2: some_extraordinary_work2; retry;
  33. >        when condition3: some_extraordinary_work3; retry;
  34. >        when condition4: return null;
  35. >      }
  36. >
  37. >is certainly better than:
  38. >
  39. >    result = do_something();
  40. >    exceptional_condition = check_error_message();
  41. >    while (exceptional_condition)
  42. >    {
  43. >        if (exceptional_condition==condition4)
  44. >        {
  45. >        result = null;
  46. >        break;
  47. >        }
  48. >        switch (exceptional_condition)
  49. >        {
  50. >        case condition1:
  51. >            some_extraordinary_work1;
  52. >            do_something();
  53. >            break;
  54. >        case condition2:
  55. >            some_extraordinary_work2;
  56. >            do_something();
  57. >            break;
  58. >        case condition3:
  59. >            some_extraordinary_work3;
  60. >            do_something();
  61. >            break;
  62. >        }
  63. >    }
  64.  
  65. This is an unfair comparison, since the latter example code uses C++ features
  66. badly.  It's wordiness is more an artifact of the switch syntax than
  67. exception semantics.  I offer the following pseudocode as an improved 
  68. version.  It presumes that unusual conditions throw an exception, so it
  69. does not make calls to the hypothetical "check_error_message".
  70.  
  71.     bool retry;
  72.     do {
  73.     retry = false;
  74.     try {
  75.         result = do_something();
  76.     }
  77.     catch( condition1 ) {some_extraordinary_work1();  retry=true;}
  78.     catch( condition2 ) {some_extraordinary_work2();  retry=true;}
  79.     catch( condition3 ) {some_extraordinary_work3();  retry=true;}
  80.         catch( condition4 ) {result=NULL;}
  81.     } while( retry );
  82.  
  83. >Oh, well! It takes me ten time longer to figure out the second piece of
  84. >code and I am still not sure whether this code is correct or not. After
  85. >a second look, yes, there are errors! "check_error_message()" should also
  86. >be called in the loop to get the new exceptional condition after a retry.
  87.  
  88. The error is obscured by poor design/coding, not language features.
  89. The example peels off the first loop iteration unnecessarily,
  90. leading to extra verbosity and obscuring the loop structure.
  91.  
  92. Arch D. Robison                
  93. Lead Developer for Photon C++        Kuck & Associates Inc.
  94. robison@kai.com             1906 Fox Drive
  95. 217-356-2288                   Champaign IL 61820
  96.